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REMARKS 

In a February 3, 2011 final office action. Examiner rejected claim 1 (the only 
independent claim) under 35 IJ.S.C. § 103(a) as being unpatenlable over U.S. Patent No. 
7,061,876 ("Ambe") in view of United States Patent Application No. 2003/0223358 
("Rigby") and further in view of U.S. Patent No. 7,197,008 ("Shabtay"). 

Applicant previously argued that claim 1 distinguishes over the Ambe, Rigby and 
Shabtay references because it claims "receiving a packet, wherein the packet comprises a 
route indicator field further comprising at least one bit that indicates a link type" and 
"responsive to the packet being received after a time of failure along a communication link 
between two of the plurality of nodes and in response to a change of state of the at least 
one bit that indicates the link type in the route indicator field in response to a node 
detecting a link failure, transmitting the packet along a second route in the system to 
another node in the plurality of nodes, wherein the second route differs from the first route 
and is identified prior to the time of failure." 

In describing these limitations involving a route indicator field, the application 

states in relevant part: 

Figure 2 illustrates a packet format 20 according to a 
prefeired embodiment and for use in connection with system 
10 of Figure la. Packet format 20 includes various fields as 
known in the Ethernet art, and only some of which are 
shown by way of example. These fields include a source 
address field 20], a destination address field 2O2, a length 
field 2O3 and a data payload field 2O4. Other fields, although 
not shown, may be included as also known in the art, such as 
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a preamble and a packet (or frame) start field. According to 
the preferred embodiment, however, packet format 20 
includes an additional field 2O5, referred to hereafter as a link 
type field 2O5. Link type field 2O5 is so named because, as 
shown below, the state of the field indicates the type of link 
on to which the packet is routed, with one state in field 2O5 
(e.g., 0) indicating a spanning tree link and another state in 
field 2O5 (e.g., 1) indicating a bypass link along system 10. 
in the preferred embodiment, link type field 2O5 is a one-bit 
field and it is contemplated that it could be a bit provided as 
an addition to existing Ethernet frames or, alternatively, it 
could be a bit that is already in the Ethernet frame yet where 
the function of that bit is changed to be consistent with the 
functionality described in this document as relating to link 
type field 2O5. 



See Patent Application, p. 9. The Application further states: 

When a failure occurs in a link in system 10, that failure is 
detected according to known protocols. However, as an 
enhancement in a preferred embodiment, in response to the 
failure detection, a node within system 10 changes the state 
of link type field 2O5 so that each packet so changed will be 
routed along a bypass link, where recall by way of example 
that a binary value of 1 in link type field 2O5 causes this 
effect. Further, when a node within system 10 receives a 
packet with a binary value of 1 in its link type field 2O5, the 
receiving node does not consult its forwarding table for 
purposes of further routing the received packet, but instead it 
consults its bypass table to determine the next route for the 
received packet. 



See Patent Application, p. 11. The route indicator field is further defined by Applicant as 
follows: 

In system 10, the route indicator field is a link type field 2O5, 
operable to indicate that the packet is to continue along a 
spanning tree route or a bypass route. In system 10', the 
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route indicator field is a link set field 20'3, operable to 
indicate that the packet is to continue along a fu st set of links 
forming a first route, a second set of links forming a second 
route, and so forth for up to 2^ sets of links corresponding to 
a respective number of 2^ routes. 

Examiner cited Shabtay as disclosing some of the language in the "responsive to 
the packet being received after a time of failure along a communication link between two 
of the plurality of nodes and in response to a change of state of the at least one bit that 
indicates the link type in the route indicator field in response to a node detecting a link 
failure, transmitting the packet along a second route in the system to another node in the 
plurality of nodes, wherein the second route differs fix)m the first route" limitation. 

However, the cited portion of Shabtay (column 13, lines 3-18) discloses a local 
protection flag bit being added to the flags field of an operation, administration and 
maintenance (0AM) packet to notify edge nodes of the use of local protection tunnels 
along a path. The network processor associated with a failed link examines the inbound 
packets received from each link and if an 0AM packet has also been received, it is 
checked if the packet is to be sent over the protection tunnel. In each OAM message to be 
rerouted to the protection tunnel, the network processor sets the local protection bit. 
Hence, Shabtay involves adding a flag bit to the flag field of the OAM packet at an 
intermediate node rather than changing the state of an existing bit in a packet at a receiving 
node. In other words, Shabtay's flag bit is not contained within the inbound packet at the 
node receiving/transmitting the packet but is added to a separate packet (OAM packet) at 
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an intermediate node and sent as a notification mechanism to indicate that local protection 
is in place along a certain path. 

In the final office action, Examiner indicated that the present claim language does 
not expressly require that the changing of the state of the at least one bit indicating the link 
type is performed by the node receiving and transmitting the packet. In other words, the 
claim language does not require that the receiving/transmitting node be the same as the 
node detecting a link failure. Therefore, Examiner submits that the current claim language, 
given its broadest reasonable interpretation, permits that the receiving/transmitting node 
may receive a packet comprising a bit that has ah-eady changed state at an intermediate 
node. Accordingly, Applicant has made appropriate amendments to independent claim 1 
to further distinguish over the cited prior art. 

Applicant respectfully requests the Examiner withdraw the rejection and allow 
pending Claim 1. In addition, all claims depending from Claim 1 either directly or 
indirectly, including Claims 2-20, are also allowable for the reasons discussed in 
conjunction with Claim 1. 
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CONCLUSION 

Applicant has made an earnest attempt to place this case in condition for allowance. 
For the foregoing reasons and for reasons clearly apparent. Applicant respectfully requests 
full allowance of all pending claims. If there are any matters that can be discussed by 
telephone to further the prosecution of this Application, Applicant invites the Examiner to 
contact the undersigned attorney at 512-306-8533 at the Examiner's convenience. 

Respectfully submitted. 

By: /Gregory S. Donahue/ 
Gregory S. Donahue 
Reg. No. 47,531 



Correspondence Address: 

Alcatel Lucent 

do Galasso & Associates, LP 

P.O. Box 26503 

Austin, Texas 78755-0503 

(512) 306-8533 telephone 

(512) 306-8559 fax 
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